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ABSTRACT 


This  report  is  the  proposed  system  concept  for  the  real-time 
processing  of  AUTODIN  messages  at  the  Data  Services  Center,  HQ,  USAF. 
It  is  composed  of  three  major  elements,  a  description  of  the  present 
system,  the  proposed  system,  and  analysis  and  conclusions  supporting  the 
proposed  system.  The  description  of  the  present  system  highlights  the 
principal  elements  of  control  in  a  manner  designed  to  emphasize  the  batch 
processing  nature  of  the  present  computer  programs,  and  their  inter¬ 
relationship  with  each  other  and  with  the  manual  RCS  control  system.  The 
problems  that  characterize  the  present  system  are  principally  those  of  the 
time  that  elapses  between  receipt  of  a  message  on  the  AUTODIN  terminal 
and  the  identification  of  errors  that  invalidate  the  message  and  require 
further  contact  with  the  originator  to  correct  the  errors.  The  manual  RCS 
control  file  was  identified  as  being  one  of  the  major  elements  of  this  time 
lapse  because  of  the  periodic  manual  transcription  of  incoming  messages 
to  handwritten  control  cards.  The  proposed  system  emphasizes  the 
desirability  of  performing  data  edits  immediately  upon  receipt  of  each 
message  and  the  instantaneous  transmission  of  an  error  message  to  the 
originator  when  the  incoming  message  has  failed  a  format  edit.  The  real¬ 
time  concept  is  also  the  main  element  of  management  control  through  the 
Command  and  Query  Terminal  that  provides  on-line  management  decision¬ 
making  ability  without  sacrificing  any  of  the  advantages  of  the  computer- 
controlled  real-time  system. 
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SECTION  I 


INTRODUCTION 


The  objective  of  Phase  I  of  this  contract  is  to  develop  a  system  concept 
for  the  efficient  real-time  processing  of  AUTODIN  messages  for  the  Data 
Services  Center,  HQ,  USAF. 

Within  the  context  of  the  operational  requirements,  efficient  real-time 
processing  means  providing  as  much  additional  speed  in  editing,  logging, 
storing  and  manipulating  messages  as  the  function  can  benefit  from  at  a 
reasonable  cost.  In  this  case,  the  speed  of  the  AUTODIN  line  (2400  baud) 
provides  a  preestablished  criteria  on  which  to  build  system  capability. 

That  is,  there  is  no  advantage  in  substituting  a  faster  line  because  the 
present  line  is  capable  of  adequately  handling  peak  load  traffic.  The  system 
can,  however,  benefit  from  improved  time  lapse  once  a  message  has  been 
received.  Essentially,  these  improvements  are  the  placing  of  all  format 
edits  at  the  earliest  possible  point  in  the  processing  cycle  to  enable  the 
system  to  identify  format  errors  and  generate  error  messages  within 
seconds  after  receipt  of  the  message. 

The  real-time  element  of  message  logging  and  storage  in  the  proposed 
system  is  the  immediate  logging  and  transfer  of  a  message  to  the  mass 
random  storage  device  following  the  format  edits.  A  message  is,  therefore, 
Musablen  seconds  after  it  is  received  in  that  it  is  entered  in  a  log  that  can  be 
queried.  At  this  point  in  the  processing  cycle,  the  man-machine  interface 
begins.  The  query  terminal  operator  can  determine  whether  the  message 
is  available  for  further  processing.  If  the  message  was  the  final  message 
for  an  RCS,  the  Command  terminal  operator  would  have  received  an  auto¬ 
matic  alert  from  the  system  informing  him  that  the  RCS  was  complete  and 
ready  for  extracting.  The  Command  terminal  operator  will  also  receive  an 
automatic  alert  for  each  message  that  fails  the  format  edit  test.  He  can 
display  the  headers  and  trailers  on  the  terminal  cathode  ray  tube  and,  if  he 
determines  that  the  error  is  correctable,  he  can  key-in  the  correct  entry 
and  transfer  the  message  to  the  regular  storage  area. 
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SECTION  II 


DESCRIPTION  OF  THE  PRESENT  SYSTEM 


A.  Incoming  Message  Procedures 

The  current  system  can  be  characterized  as  a  series  of  batch 
processing  runs  that  perform  rudimentary  format  edits,  as  shown  in 
Figure  1.  One  of  these  programs  (LOGER)  provides  a  listing  of  in¬ 
coming  messages  that  is  manually  transcribed  to  control  cards.  This 
manually  maintained  RCS  control  file  is  the  hub  of  the  present  system 
in  that  the  Data  Services  Division  is  totally  dependent  upon  it  for 
accurate,  up-to-date  information  necessary  to  schedule  data  editing 
and  report  production  runs. 

Manual  RCS  Control  Procedures 


Step  1 :  Set  up  an  AFHQ  0-209  card  for  each  incoming  RCS. 

There  will  be  a  separate  card  for  each  Command  that 
is  required  to  submit  a  particular  RCS.  Set-up  consists 
of  recording  RCS  number,  Command  symbol,  as  of  date, 
due  date,  classification  and  card  number. 


Step  2 :  Delinquency  Control:  Twenty-four  hours  after  an  RCS 

is  due,  a  delinquency  notice  message  (TWX,  telephone, 
etc.  )  is  sent  to  each  Command  that  has  not  transmitted 
a  complete  RCS. 

Step  3:  Message  Logging:  Upon  receipt  of  the  first  trans¬ 

mission  from  each  Command  of  an  RCS,  the  following 
items  of  information  are  extracted  from  the  LOGER  list 
and  recorded  on  the  AUTODIN  Control  Card. 


a) 

Mailed  data  b) 
only 

c) 

d) 

e) 


Date 

903  card  shipment  number,  card  count  or  reel 
number 

LOGER  tape  reel  number 
LOGER  message  number 

Control  Number  -  in  this  case,  nln  indicates 
that  this  is  the  first  AUTODIN  Terminal  tape  reel 
containing  messages  for  the  indicated  Command 
and  RCS. 
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Incoming 


Messages 


To 

Print  ’ 
Run  „ 


_ I _ 

1401  CHATT 
or  7080  Edit 


Figure  1:  PRESENT  SYSTEM  -  INCOMING  MESSAGES 
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Step  3: 

Message  Logging  (Continued) 

f)  Recording  of  receipt  of  each  Command  Message 
Number  is  accomplished  by  writing  the  Control 
Number  in  each  block  representing  a  Command 
Message  Number.  That  is,  if  this  is  Control 
Number  1  (first  AUTODIN  Tape  for  this  Command 
and  RCS)  and  Command  Message  Numbers  1,  6, 

10  and  12  are  on  that  tape,  then  a  1  is  written  in 
blocks  1,  6,  10  and  12. 

g)  Each  message  on  the  LOGER  that  is  a  duplicate  of 
one  already  logged  is  crossed  out.  That  is,  the 
first  transmission  is  used. 

h)  A  Resubmission  message,  identified  by  an  MRM  in 
position  32  of  the  Text  Header,  must  be  substituted 
for  the  original  message.  There  is  no  way  of 
correcting  the  specific  error  field  or  fields,  the 
entire  MRM  message  is  substituted. 

Step  4: 

Format  Edits:  AUTODIN  Header  and  Trailer  and  Text 

Header  and  Trailer  are  scanned  for  errors. 

B.  Outgoing  Message  Procedures 

In  the  present  system,  as  shown  in  Figure  2,  all  cards  to  be 
sent  out  are  first  put  on  magnetic  tape.  The  following  discussion 
enumerates  the  several  steps  in  this  process: 


Step  1 : 

The  number  of  the  requested  tape  to  be  sent  out  is  taken 
to  the  AUTODIN  Management  Section.  In  new  or  one¬ 
time  transmissions,  the  necessary  information  to  fill 
out  the  Message  Build  Routine  (BILDR)  control  cards 
must  be  provided.  In  recurring  report,  only  the  record 
count,  "As  of  Date11,  and  any  change  in  addressee 
information  must  be  provided  since  control  cards  are  on 
file.  The  AUTODIN  Standard  Job  Register  is  used  for 
this  purpose. 

Step  2: 

The  AUTODIN  Management  Section  will  then  assign  an 
arbitrary  station  serial  number  sequence  according  to 
the  record  count  of  the  outgoing  data.  (Allow  40,  000 
characters  per  message.  )  The  station  serial  number 
sequence,  the  RCS  of  the  outgoing  data  and  the  date  are 
then  entered  into  the  station  serial  number  log.  (See 
Figure  3.  ) 
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Outgoing  Messages 


\ 

\ 

\ 

\ 

AUT(^DIN 

Management 

Section 


Figure  2:  PRESENT  SYSTEM  -  OUTGOING  MESSAGES 
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STATION  SERIAL  NO. 

DATE 

REMARKS 

START 

STOP 

RCS 

1230 

1241 

AR3092F 

6  Feb 

1243 

AF-C147 

6  Feb 

1244 

1262 

1 

MAP/EAM 

I 

l 

8  Feb 

Figure  3:  STATION  SERIAL,  NUMBER  LOG 
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B.  Outgoing  Message  Procedures  (Continued) 


Step  3: 

The  data  tape  number  and  the  BILDR  control  cards, 
along  with  any  ADP  Services  request  forms,  are  sent  to 
the  operations  sections. 

Step  4: 

The  BILDR  Program  is  then  run  on  the  1401  using  the 
control  cards  and  the  data  tape  from  Step  3  as  input. 

This  program  uses  the  control  cards  to  obtain  the 
necessary  information  for  the  AUTODIN  and  Text  Headers 
and  Trailers.  The  builder  program  segments  the  data 
into  one  or  more  messages  of  40,  000  characters 
(including  Header  and  Trailers).  The  output  message 
tape  number  and  the  log  from  the  builder  program  is 
then  returned  to  the  AUTODIN  Management  Section.  The 
data  reel  is  returned  to  the  library. 

Step  5: 

Upon  receipt  of  the  builder  log  and  output  tape  reel 
number,  an  entry  is  made  in  the  tape  reel  log  (Figure  4). 
The  remarks  column  is  used  to  record  RCS  content  of 
the  tape. 

Step  6: 

The  BILDR  log  and  tape  reel  are  then  sent  to  the 

AUTODIN  terminal  for  transmission. 

Step  7: 

At  the  AUTODIN  terminal,  the  transmission  time  of 
each  of  the  messages  of  the  total  data  transmission  is 
recorded  and  any  error  conditions  indicated.  The 
builder  log,  on  which  the  times  have  been  recorded,  is 
then  returned  to  the  AUTODIN  Management  Section.  The 
output  reel  is  returned  to  the  library. 

Additional  Actions 

1.  Daily  counts  are  kept  of  the  messages  transmitted  and  retransmitted 
in  the  AUTODIN  Traffic  Log.  (Figure  5) 

2.  Monthly  totals  of  outgoing  traffic  are  also  recorded. 
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DATE  FRCC 

REEL  NO. 

DATE  RETCC 

REMARKS 

20  Feb 

10134 

23  Feb 

ADC-D12 

20  Feb 

10110 

CSU-PD 

21  Feb 

1601 1 

AU-S5 

22  Feb 

10234 

RAC-PD  (Mail 

FRCC  -  From  Computer  Center 

RETCC  -  Returned  to  Computer  Center 


Figure  4:  REEL  LOG 
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IN 

OUT 

Feb 

Reg 

Tran 

Retran 

'67 

DATE 

MSG 

RC 

MSG 

RC 

Total 

Record  Count 

1 

4 

1, 729 

1 

500 

2 

49 

23,  935 

r 

500 

TOTAL 

MSG 

RC 

Reg  Tran 
Re-Tran 


Messages 

Records 

Regular  Transmission 
Re -Transmission 


Figure  5:  AUTODIN  TRAFFIC  LOG 
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SECTION  III 


PROPOSED  SYSTEM 


A,  Incoming  Messages 

The  processing  and  storage  of  incoming  traffic,  as  shown  in 
Figure  7,  is  composed  of  the  following  major  functions: 

1.  Format  Editing 

2.  Error  Message  Generation 

3.  Message  Logging  and  Statistics 

4.  Message  Storage  and  Retrieval 

5.  Automatic  Alert  Generation 

6.  Printing  of  Selected  Messages 


Figure  6:  PROPOSED  SYSTEM  -  PROCESSING  OF  INCOMING  TRAFFIC 
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A.  Incoming  Messages  (continued) 


1.  Format  Editing:  See  list  of  header  and  trailer  format  edits  in  the 

Appendix,  In  addition  to  those  edits,  each  detail  record  will  be 
checked  to  determine  if  the  Command  Code  is  in  the  column(s) 
specified  for  the  RCS  entry  in  the  Text  Header  and  Text  Trailer. 

The  detail  record  Command  Code  will  also  be  compared  to  the 
Command  Code  in  the  Text  Header.  These  two  edits  will  insure 
that  the  detail  records  apply  to  the  proper  RCS  and  Command, 

Z.  Error  Message  Generation:  Detection  of  critical  format  errors 

will  cause  a  system- generated  error  message  to  be  automatically 
formatted  and  stored  on  the  disks  for  transmission.  Under  normal 
operating  conditions,  this  error  message  will  be  transmitted 
almost  immediately. 

3.  Message  Dogging  and  Statistics:  All  incoming  messages  will  be 

logged  in  essentially  the  same  format  used  in  the  present  system. 
This  log  will  be  listed  on  the  line  printer  daily.  The  operational 
nlogn  will  consist  of  a  series  of  tables  for  each  RCS  listing  every 
reporting  Command  for  that  RCS.  A  more  detailed  "log"  will  con¬ 
sist  of  a  separate  table  for  each  reporting  Command  under  each 
RCS.  This  detailed  table  will  list  every  message  transmitted.  The 
real-time  logging  of  incoming  RCS's  will  provide  the  inquiry 
terminals  with  the  accurate,  up-to-date  data  necessary  to  efficiently 
schedule  data  edits  and  report  production.  These  tables  will  also 
provide  the  necessary  data  to  generate  periodic  traffic  statistics 

by  RCS. 

4.  Message  Storage:  RCS  messages  will  be  stored  on  a  mass  random 

access  device  within  seconds  after  they  are  received.  At  this 
point,  a  message  is  available  for  random  access  retrieval  on 
command  from  the  AUTODIN  Command  and  Query  Terminal  (ACQT). 

5.  Automatic  Alert  Generation:  Although  the  ACQT  operator  will  be 

able  to  set  a  series  of  alerts  relating  to  incoming  traffic,  there  is 

a  need  for  a  series  of  system-generated  alerts  based  on  RCS  status 
at  the  time  of  message  receipt.  When  a  message  is  received  for  an 
RCS  that  has  already  been  dumped  to  tape  for  data  editing  and 
report  production,  an  alert  will  be  transmitted  to  the  ACQT  (CRT 
and  hard  copy)  indicating  whether  the  message  is  a  Resubmission 
or  a  duplicate.  The  message  will  be  stored  in  the  Suspense  File 
section  of  the  mass  random  device.  If  the  operator  is  advised  that 
the  message  is  needed,  he  can  use  the  ACQT  to  dump  it  to  tape. 
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5.  Automatic  Alert  Generation  (Continued) 

When  a  message  is  received  that  is  a  duplicate  of  a  message 
already  stored  on  the  mass  random  device,  an  alert  will  be 
generated,  including  the  headers  and  trailers  of  the  duplicate 
message. 

6.  Printing  of  Selected  Messages:  The  system  will  print  all  teletype 

messages  on  the  line  printer.  Any  Single  Card  (SC)  format  message 
that  is  not  a  negative  RCS  report  will  also  be  printed.  In  addition 

to  these  system-generated  printouts,  the  ACQT  operator  may  print 
out  any  message  that  is  stored  on  the  mass  random  device, 

B.  Terminal  Functions 


This  section  enumerates  the  various  query  and  control  terminal 
users.  Certain  of  these  are  special  requests  that  can  only  be  executed 
by  the  Command  terminal;  these  are  system  maintenance  operations  and 
functions  requiring  machine  operator  scheduling,  and  are  marked  with 
an  asterisk  (*)  in  the  following  discussion. 

Hard  copy  will  be  available  of  any  CRT  display  upon  user  request, 
some  immediately  via  the  console  typewriter,  and  others,  necessarily 
of  lower  priority,  via  the  system  line  printer. 


Command  and  Query  Terminal  Query  Terminal 
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Table  I:  TERMINAL  FUNCTIONS 


Function 

Type 

Function 

# 

Function 

Name 

Approximate 
Response  Time 

Remarks 

RCS 

STATUS 

1 

Total  System 
Summary  • 

10  Minutes 

A  CRT  display  showing 
the  number  of  RCSfs 
complete,  incomplete 
and  complete  but 
awaiting  messages 

2 

Total  System 
Report 

10  Minutes 

Function  #1  plus  a 
detailed  report  on  the 
line  printer  showing  the 
status  of  each  RCS  by 
reporting  Commands. 

3 

RCS  Status 

10  Seconds 

Status  report  for  a 
designated  RCS.  It  wiL 
show  status  and  mes¬ 
sage  counts  for  each 
reporting  Command. 

4 

RCS  Status 
by  Command 

5  Seconds 

Selected  RCS  and 
specified  Command 
Status,  message  count 
and  missing  message 
numbers. 

ALERTS 

* 

1 

RCS  Alert 

5  Seconds 

Report  upon  completion 
of  all  reporting  Com¬ 
mands  for  one  RCS  or 
upon  individual  Com¬ 
mand  completion. 

2 

RCS  Command 

Alert 

5  Seconds 

Report  is  generated 
each  time  a  message 
arrives  for  the  speci¬ 
fied  Command  of  the 
selected  RCS. 

3 

RCS  Command 
Message  Alert 

5  Seconds 

Report  when  a  speci¬ 
fied  message  is 
received. 

*  These  functions  apply  only  to  the  Command  Terminal. 
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Table  I:  TERMINAL  FUNCTIONS  (Continued) 


Function 

Type 

F  unction 

# 

Function 

Name 

Approximate 
Response  Time 

Remarks 

FILE 

EXTRACTS 

1 

RCS  Extract 

5-30  Minutes 

All  reporting  Commands 
of  the  specified  RCS  are 
dumped  to  tape. 

2 

Command 

Extract 

15  Seconds 

The  selected  Command 
of  the  specified  RCS  is 
dumped. 

3 

Message 

Extract 

5  Seconds 

A  single  message  is 
dumped. 

MESSAGE 

TRANS¬ 

MISSION 

1 

Service 

Messages 

-  -  - 

Command  terminal 
operator  keys-in 
narrative  messages. 

2 

Retrans¬ 

missions 

15  Seconds 

Operator  calls  in  mes¬ 
sage  from  mass  random 
and  keys-in  new  date¬ 
time  entries. 

FILE  AND 

TABLE 

MAINTE¬ 

NANCE 

1 

Table 

Maintenance 

-  -  - 

Command  terminal 
operator  will  be  able  to 
update  all  core  and  disk 
tables. 

2 

File 

Maintenance 

-  -  - 

Operator  will  be  able  to 
allocate  and  deallocate 

disks  and  mass  random 
storage. 

These  functions  apply  only  to  the  Command  Terminal. 
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C.  Outgoing  Messages 


The  system  will  operate  in  full-duplex  mode.  The  bulk  of  the  out¬ 
going  traffic  will  be  delivered  to  the  AUTODIN  computer  operator  in 
magnetic  tape  format.  This  tape  will  be  the  input  to  the  on-line  version 
of  the  BIL.DR  Program,  as  shown  in  Figure  9.  These  assembled 
messages  will  be  stored  on  a  disk  and  transmitted  in  order  of  precedence. 
When  a  message  has  been  transmitted,  it  will  then  be  stored  on  the  mass 
random  access  device  for  one  month  if  there  is  sufficient  storage 
available.  This  will  enable  the  ACQT  operator  to  respond  to  retrans¬ 
mission  requests  by  keying-in  the  approximate  message  identification. 
Provision  will  be  made  for  overflow  of  this  storage  area,  i.  e.  ,  in  an 
overflow  condition,  the  overflow  messages  will  be  dumped  to  magnetic 
tape  storage;  in  this  way,  the  most  recent  outgoing  traffic  that  is  more 
likely  to  require  retransmission  will  be  available  in  random  access 
storage. 

Error  messages,  generated  when  an  incoming  message  fails  an 
edit  routine,  will  be  stored  in  a  core  buffer.  In  addition,  since  the 
error  messages  will  tend  to  be  rather  short,  they  will  have  a  trans¬ 
mission  priority  over  the  normal  outgoing  traffic. 

Service  messages  may  be  entered  into  the  regular  stream  of  out¬ 
going  messages  on  magnetic  tape,  or  they  may  be  nkeyed-inM  by  the 
ACQT  operator. 


Figure  8:  PROPOSED  SYSTEM  -  PROCESSING  OF  OUTGOING  TRAFFIC 
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D.  Program  Maintenance  and  System  Statistics 


1.  Maintenance:  Due  to  the  dynamic  nature  of  RCS  reporting 

requirements,  the  AUTODIN  control  system  must  be  flexible 
epough  to  adapt  to  changing  needs.  The  system  must  be  capable 
of  handling  additional  RCSfs,  dropping  RCS's,  adding  new 
reporting  Commands  to  existing  RCS's,  as  well  as  the  many  per¬ 
mutations  of  additions,  deletions  and  modifications. 

In  order  to  facilitate  these  changes,  a  number  of  system 
maintenance  functions  will  be  available  to  the  ACQT.  Without 
taking  the  system  off  line,  the  operator  will  be  able  to  reconfigure, 
modify  and  expand  the  system's  capability.  Only  in  limited  circum- 
cumstances  will  the  system  be  required  to  shut  down  for  software 
system  maintenances. 

The  maintenance  function  will  include  the  necessary  modules 
to  provide  periodic  dumping  of  critical  files  and  tables  to  magnetic 
tape  for  backup  in  case  of  file  destruction. 

2.  Statistics :  The  AUTODIN  control  system  will  provide  detailed 

statistics  covering  both  normal  operations  and  system  performance. 

The  operations  statistics  will  consist  of  reports  concerning  the 
activity  of  the  system  over  a  previous  pre-set  period.  It  will 
include  such  information  as  incoming  message  counts,  outgoing 
message  counts,  error  totals  by  RCS  and/or  Commands,  and  record 
totals,  by  Command  and  RCS. 

The  system  performance  statistics  will  be  used  by  the  group 
responsible  for  system  maintenance.  They  will  contain  such 
information  as  table  size,  mass  random  allocations,  overflow  con¬ 
ditions  and  file  activity.  By  use  of  these  reports  and  the  system 
maintenance  functions,  the  AUTODIN  control  system  can  be 
reconfigured  to  increase  efficiency  and  reliability. 

E.  System  Recovery  Procedures 

In  order  to  permit  the  system  to  continue  operation  in  a  degraded 
mode,  due  to  equipment  malfunction,  a  set  of  backup  procedures  will 
be  developed.  This  graceful  degradation  process  will  permit  continu¬ 
ation  of  those  functions  which  are  independent  of  down  devices.  Upon 
restoration  of  down  devices,  the  system  will  recover  lost  functions. 
Devices  will  be  declared  "down"  by  the  operator  or  the  software  system. 
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E.  System  Recovery  Procedures  (Continued) 


1.  Communications  Lines  Procedures: 

a.  Inline  -  none 

b.  Outline  -  no  transmission  of  messages.  Error  messages 
from  Inline  will  be  stored  on  disk. 

2.  Mass  Random  Procedures: 

a.  No  incoming  traffic  will  be  stored.  A  tape  will  be  used  as 
a  buffer  till  the  device  is  repaired.  If  a  tape  is  not 
available,  the  switching  center  will  be  requested  to  stop 
sending. 

b.  No  tape  dumps  are  possible. 

3.  Disk  Procedures:  Disk  #1  is  dedicated  to  operating  system 

residence;  therefore,  Disk  #1  must  always  be  available.  If  it 
malfunctions,  Disk  #2  will  assume  systems  residence.  In  this 
mode,  input  traffic  will  be  put  on  to  tape.  No  outgoing  traffic 
or  query  capability  will  be  possible. 

4.  Tape  Procedures:  Tape  #1  and  Tape  #2  will  alternate  in  function. 

If  one  tape  is  down,  only  one  of  the  dump  or  tape  transmission 
functions  will  be  allowed. 

5.  CRT  Procedures:  Limited  query  and  dumping  functions  will  be 

permitted  by  use  of  the  card  reader  and  printer. 

F.  Operating  System  and  Software  Utilization 

1.  Communications  Lines:  The  manufacturer  will  provide,  in 

addition  to  the  AUTODIN  buffer  hardware,  a  set  of  software  to 
interface  with  the  pseudo  communications  language  to  be  developed 
in  Phase  2.  The  pseudo  communications  language  will  be  a  set  of 
I/O  calls  to  the  communications  line  handlers  permitting  reading, 
writing,  and  line  control.  Error  control  will  be  handled  by  the 
hardware  and  manufacturers  software.  The  pseudo  language  will 
permit  detail  system  design  without  actual  communications  soft¬ 
ware.  The  pseudo  language  will  be  general  enough  to  permit 
modifications,  tailoring  it  to  the  hardware  without  excess  design 
modifications. 
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F.  Operating  System  and  Software  Utilization  (Continued) 


2.  Random  Access:  The  manufacturers  will  provide  a  set  of 

handlers  for  each  type  of  random  access  device  specified.  They 
will  be  capable  of  operating  in  either  sequential  or  random  modes. 

3.  Card  Devices;  The  manufacturers  will  provide  a  set  of  card 
device  handlers. 

4.  Tape  Devices:  The  manufacturers  will  provide  a  set  of 

magnetic  tape  device  handlers. 

5.  Real-Time  Clock:  The  software  will  be  provided  to  permit 

access  to  the  real-time  clock  for  both  time  stamping  and  interrupt 
action. 

6.  Multi-  Programming:  To  permit  the  many  asynchronous  tasks  to 

operate  in  the  system  concurrently,  a  multi-programming  facility 
is  necessary.  The  manufacturers  will  provide  an  operating  system 
with  sufficient  levels  to  support  the  system  and  at  least  one  back¬ 
ground  job. 

7.  Display  Terminals:  The  manufacturers  will  provide  a  set  of 

software  to  permit  full  control  of  the  display  terminals  to  include 
request  attention  interrupts. 

G.  System  Design  Philosophy 

In  order  to  design  a  system  which  will  have  to  have  both  machine 
and  software  independence,  a  modularity  approach  will  be  taken.  The 
system  functions  will  be  broken  up  into  asynchronous  modules,  and 
each  will  be  able  to  run  concurrently  in  a  multi-programming  environ¬ 
ment,  dependent  only  upon  its  activation  criteria  and  input/output  file 
priority.  Additionally,  interlocks  will  be  designed  into  each  module 
to  prevent  the  transmission  of  erroneous  information  to  other  modules. 
An  example  of  interlock  would  be  to  prohibit  two  modules  from  making 
entries  into  the  same  Command  message  table  simultaneously.  When 
the  actual  hardware  and  its  supporting  software  is  known,  the  modules 
will  be  fitted  with  the  operating  system  to  produce  the  final  system. 

A  standard  format  will  be  adopted  for  module  documentation.  The 
documentation  will  contain: 

1.  Activation  Criteria:  The  conditions  necessary  for  the  module 

to  start  execution. 
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G.  System  Design  Philosophy  (Continued) 


20  1/ O  Priority:  The  priority  which  the  module  will  have  for 

reference  to  each  file  it  uses.  The  priority  is  determined  by  the 
effect  of  I/O  delay  upon  total  system  performance. 

3o  Interlocks :  The  interlock  conditions  and  the  action  to  be  taken 

upon  recognition  of  such. 

4.  Common  Module  Communications  Pool  Reference:  The  infor¬ 

mation  that  the  module  must  update  or  check  in  the  common 
module  communications  pool. 

5.  Detail  Flow  Charts 

6.  Flow  Chart  Narrative  Descriptions 
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SECTION  IV 


CONCLUSIONS 


Although  the  present  system  encompasses  most  desirable  controls, 
there  are  a  number  of  inherent  characteristics  of  the  system  that  severely 
limit  its  overall  effectiveness. 

One  of  the  more  effective  means  of  isolating,  understanding  and  solving 
system  difficulties  is  to  trace  the  flow  of  a  transaction  through  all  facets  of 
the  system  as  a  means  of  exploring  the  effectiveness  of  the  processing  of 
abnormal  as  well  as  normal  transactions. 

The  present  AUTODIN  terminal  accepts  messages  and  stores  them  on 
reels  of  magnetic  tape  that,  under  normal  operating  conditions,  are  re¬ 
moved  from  the  AUTODIN  terminal  tape  drive  approximately  every  eight 
hours.  This  input  tape  is  then  scheduled  for  processing  by  the  1401  LOGER 
Program.  For  the  sake  of  example,  let  us  assume  that  the  first  message  on 
this  tape  is  a  narrative  teletype  message.  That  is,  a  message  we  "received" 
eight  to  twelve  hours  ago  is  now,  for  the  first  time,  about  to  be  subjected 
to  some  sort  of  processing.  The  teletype  message  will  now  be  printed  on 
the  1401  printer  and  be  available  for  some  sort  of  further  action  based  on 
human  decision. 

If  the  originator  of  this  teletype  message  was  concerned  about  the 
length  of  time  necessary  to  transmit  the  message,  he  may  have  assigned  a 
priority  precedence  code.  The  priority  code  would  have  accelerated  the 
transmission  of  the  message  to  the  AUTODIN  terminal  but,  from  that  point 
on,  the  priority  designation  would  have  absolutely  no  value  within  the 
framework  of  the  present  system.  Therefore,  an  originating  station  that 
is  truly  concerned  about  the  time  is  forced  to  use  some  other  means  of 
communications  in  order  to  insure  considerably  earlier  action  by  human 
intervention.  The  transmitter,  having  made  such  a  decision,  has  exercised 
good  judgment,  and  has  also  characterized  one  of  the  more  critical  short¬ 
comings  of  the  present  system. 

Delays  of  this  type  are  even  more  significant  if  one  traces  an  RCS 
message  under  similar  circumstances.  The  RCS  message  would  be  subject 
to  the  same  delays  at  the  magnetic  tape  terminal.  If  the  message  were  an 
!TXn  or  "Y"  precedence,  it  would  be  printed  out  by  the  1401  LOGER  Pro¬ 
gram.  In  this  case,  an  RCS  message  would  have  reached  a  point  of  human 
action  at  the  same  stage  of  processing  as  the  previously  discussed  teletype 
message.  The  average  RCS  message,  however,  would  not  yet  be  subjected 
to  human  intervention.  It  would  first  be  subjected  to  format  edits  by  the 
LOGER  Program,  whereby  the  headers  and  trailers  would  be  printed  out  on 
the  log  that  is  used  for  the  manual  RCS  control  process.  This  log  is  the 
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first  point  at  which  a  regular  RCS  message  can  be  identified.  If  this  RCS 
message  is  one  that  is  necessary  to  complete  a  particular  RCS,  the 
person  transcribing  traffic  from  the  1401  log  to  the  RCS  control  cards 
would  have  been  previously  alerted  to  watch  for  it. 

Even  the  positive  identification  of  the  RCS  at  this  point  is  insufficient, 
since  further  manual  and  machine  processing  is  necessary  to  make  the 
message  available  to  the  Data  Application  Division  staff.  In  order  to  ac¬ 
complish  this,  the  message  must  next  be  scheduled  for  processing  by  the 
RITER  Program,  to  extract  the  message  from  the  magnetic  tape  that  was 
produced  by  the  LOGER  Program.  In  addition  to  the  delay  caused  by 
having  to  schedule  a  separate  RITER  run  to  extract  the  message,  there  is  a 
further  delay  in  the  machine  processing  itself,  because  the  messages  are 
stored  on  magnetic  tape  and  RITER  must  read  each  sequential  message  on 
the  tape  until  it  finds  the  one  tagged  for  extracting.  If  there  are  several 
RCS  messages  that  are  needed  to  complete  an  RCS,  and  if  they  arrive 
many  hours  apart,  they  will  be  on  separate  AUTODIN  terminal  tapes  and 
separate  LOGER  output  tapes.  This  necessitates  a  separate  RITER  extract 
from  each  of  the  LOGER  tapes  in  order  to  collate  those  messages  that  are 
holding  up  any  further  processing  of  the  RCS. 

It  is  clear  that  these  inherent  delays  in  the  present  system  are 
attributable  to  the  batch- sequential  mode  of  processing.  If  messages 
could  be  logged  immediately  upon  receipt  and  made  available  for  extraction 
on  a  direct  access  basis,  it  would  be  possible  to  complete  the  processing 
of  an  RCS  much  earlier;  perhaps  as  much  as  two  days  could  be  saved  in 
extreme  cases.  The  true  concept  of  a  real-time  system  is  that  it  should 
provide  as  fast  a  system  response  as  will  benefit  the  application.  The 
potential  benefits  of  real-time  logging,  inquiry  and  retrieval  are  rather 
evident.  A  real-time  system  with  a  mass  random  storage  device  would 
eliminate  all  of  the  scheduling  delays  that  characterize  the  present  system; 
furthermore,  it  would  provide  completely  accurate  logging,  in  place  of  the 
present  manual  logs  and  their  attendant  clerical  errors. 

The  editing  facilities  of  the  present  system  cause  even  greater  delays 
than  those  due  to  message  logging.  Selected  format  edits  are  now  per¬ 
formed  by  the  LOGER  Program,  and  message  headers  and  trailers  are 
visually  scanned  during  the  manual  RCS  logging  procedure,  but  many  other 
possible  format  checks  are  not  part  of  either  procedure.  The  present 
system  performs  rudimentary  format  edits  on  the  AUTODIN  and  text 
headers  and  trailers,  but  does  not  determine  whether  the  data  records  that 
constitute  the  message  are  for  the  RCS  and  Command  specified  by  the 
headers  and  trailers.  Thus,  it  is  possible  for  a  message  to  be  completely 
processed  and  delivered  to  the  7080  for  data  edits  and  report  production 
without  knowing  whether  the  message  is  what  it  purports  to  be.  Such 
errors  are  finally  discovered  when  the  7080  data  edit  program  hangs  up; 
but,  by  that  time  it  may  be  several  days  since  the  message  was  originally 
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received  on  the  AUTODIN  terminal.  The  Command  Code  in  the  header  and 
trailer  is  neither  validated  nor  compared  with  the  Command  Code  in  the 
data  records.  When  such  errors  are  discovered,  it  usually  requires  the 
transmission  of  a  message  to  the  originator  to  resolve  the  error.  Thus, 
the  cycle  of  system  delays  begins  all  over  again.  If  the  message  was  late 
in  the  first  place  and  was  holding  up  final  report  production,  it  is  possible 
that  the  total  delay  can  be  doubled  or  tripled. 

Some  of  the  header  and  trailer  edits  that  are  presently  performed  are 
rather  limited  in  value;  even  though  a  message  can  pass  the  edits,  at  some 
further  point  during  the  processing  cycle  it  may  nonetheless  be  necessary 
to  transmit  an  error  message  to  the  originator.  An  example  of  this  type 
of  inadequate  format  edit  is  that  performed  on  the  RCS  number.  The 
present  system  merely  checks  for  the  presence  of  an  entry  in  the  RCS 
field,  but  it  does  not  validate  the  entry.  Therefore,  it  is  possible  for  an 
illogical  RCS  number  to  enter  the  system  and  go  undiscovered  for  some 
time.  When  it  is  finally  discovered,  it  may  require  the  transmission  of 
an  error  message.  If  so,  the  cycle  of  delay  is  triggered  again. 

The  solution  to  these  recurring  delays  lies  in  the  design  of  a  real¬ 
time  edit  routine  and  error  message  generator.  The  format  edit  routine 
must  conclusively  establish  the  validity  of  the  message  as  it  is  represented 
by  both  the  AUTODIN  and  Text  headers  and  trailers.  Whenever  feasible, 
field  entries  should  be  subjected  to  absolute  validation  by  table  look-up 
procedures,  rather  than  just  checking  for  the  presence  of  an  entry.  This 
is  particularly  true  of  the  RCS  numbers  and  the  Command  Codes.  It  is 
desirable  and  feasible  to  perform  these  edits  during  receipt  of  the  message. 
Then,  if  the  message  has  not  passed  the  format  edits,  the  system  can 
immediately  generate  an  error  message  to  the  transmitting  Command. 

Operation  of  the  new  system  in  full  duplex  mode  will  permit  the 
system  to  transmit  the  error  message  as  soon  as  the  message  currently 
being  sent  is  completed,  rather  than  to  wait  until  the  current  batch  of  out¬ 
going  messages  is  completed,  as  is  the  case  with  the  present  system. 

The  inquiry  and  control  aspects  of  the  present  manual  RCS  control 
system  are  germain  to  our  analysis.  (Scheduling  batches  of  messages  for 
data  editing  and  report  production  on  the  7080)  The  process  consists  of  a 
series  of  verbal  inquiries  that  are  answered  by  looking  up  the  record  of 
received  and  missing  messages  for  the  RCS  in  question.  If  there  are 
missing  messages,  and  if  the  report  is  overdue,  it  is  necessary  to  use 
TWX  or  telephone  to  contact  the  reporting  Command.  The  heavy  demands 
upon  the  people  who  maintain  this  manual  file  are  such  that  it  is  virtually 
impossible  for  them  to  keep  the  Data  Applications  Division  staff  fully  in¬ 
formed  regarding  RCS  status.  (Even  when  missing  messages  are  manually 
logged,  it  is  still  necessary  to  schedule  them  for  extracting  by  the  RITER 
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Program.  )  These  two  critical  functions  of  RCS  status  inquiry  and  the 
control  function  of  extracting  a  message  or  contacting  the  reporting 
Command  to  request  transmission  are  also  logical  candidates  for  inclusion 
in  the  real-time  system  concept. 

When  the  accumulation  of  RCS  messages  has  reached  the  point  where 
only  a  few  more  messages  are  needed  to  complete  the  RCS,  it  is  essential 
that  the  system  be  capable  of  automatically  recognizing  RCS  completion 
so  that  there  will  be  no  delay  in  extracting  the  data  for  further  processing. 
The  control  tables  which  the  system  will  use  to  log  incoming  messages 
will  also  serve  to  answer  status  queries  and  will  provide  a  vehicle  for  the 
Command  terminal  operator  to  set  ’’alerts"  for  a  particular  message  or 
RCS  or  Command.  Once  the  operator  has  set  the  alert  flag,  it  will  be 
unnecessary  for  him  to  further  query  the  system;  rather,  the  system  will 
now  automatically  alert  him,  via  CRT  and  a  printed  message,  that  the 
designated  message  has  arrived.  The  operator  will  then  have  the  Com¬ 
mand  ability  to  direct  the  system  to  extract  that  RCS  for  further  processing 
on  the  7080.  Thus,  real-time  Command  and  control  capability  will  enable 
the  system  to  begin  extracting  an  RCS  within  seconds  or  minutes  after 
completion,  as  opposed  to  the  present  potential  systems  delay  of  many 
hours. 

Because  of  the  half-duplex  operation  of  the  present  system,  the 
sending  of  delinquency  messages  requesting  a  Command  to  transmit  mes¬ 
sages  that  are  missing  from  an  RCS  is  of  little  value.  It  is  necessary  to 
write  the  message  on  a  magnetic  tape,  whereupon  the  tape  is  subject  to 
terminal  delays  until  a  group  of  incoming  messages  has  been  received, 
before  the  terminal  can  be  used  to  transmit.  Operation  of  the  new  system 
in  full-duplex  mode,  with  the  ability  to  accept  keyed-in  messages  from 
the  Command  terminal  for  immediate  transmission,  will  provide  the  speed 
necessary  to  justify  its  use  for  such  operational  messages.  The  system 
will  be  capable  of  formatting  and  transmitting  error  messages,  delinquency 
messages  and  other  service  messages  keyed-in  by  the  Command  terminal 
operator  at  the  same  time  it  is  performing  these  functions  for  the  normal 
stream  of  outgoing  traffic.  Random  access  capability  will  enable  the 
system  to  more  readily  insert  priority  outgoing  messages  at  the  head  of 
the  message  stream. 

In  summary,  application  of  the  "real-time"  concept  to  the  AUTODIN 
System  implies  the  capacity  to  perform  the  necessary  edit,  logging, 
storage  and  inquiry  and  Command  functions  within  a  time-frame  that  will 
provide  the  optimum  effective  benefits  to  the  system  users. 

Format  edits  must  be  performed  at  the  earliest  point  possible  in  the 
data  flow  to  permit  early  transmission  of  the  error  message.  The  second 
advantage  of  performing  all  format  edits  at  the  instant  of  message  receipt 

$ 

is  that  the  system  is  relieved  of  the  wasteful  function  of  further  processing 
a  message  that  must  ultimately  be  rejected  by  the  system. 
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The  input  message  logging  function  must  immediately  follow  the  edit  routines 
if  it  is  to  adequately  support  the  inquiry  capability  of  the  system.  Any  sub¬ 
stantial  delay  between  message  validation  and  message  logging  would  present 
an  inaccurate  status  report  that  would  tend  to  degrade  the  effectiveness  of 
the  inquiry  system. 

Storage  of  incoming  and  outgoing  traffic  should  provide  the  ability  to 
extract  either  a  single  message  or  a  group  of  messages  without  the  necessity 
of  reading  through  groups  of  unwanted  messages.  The  tables  that  serve  the 
logging  function  can  perform  a  three-fold  function  in  that  they  can  log  the 
message,  answer  status  inquiries  and  provide  the  addresses  of  specified 
messages  that  are  to  be  extracted. 

Maintenance  of  a  master  file  for  the  storage  of  this  traffic  has  neces¬ 
sitated  the  analysis  and  comparison  of  various  types  of  random  access 
systems.  In  this  regard,  there  are  two  major  system  requirements  to  be 
considered: 

1.  Workload:  Although  the  RCS  and  other  traffic  volumes  may 

fluctuate  sharply  in  either  direction,  it  must  be  assumed  that  the 
potential  exists  for  a  substantial  increase  in  traffic.  The  master 
file  storage  requirement  for  all  incoming  and  outgoing  traffic  has 
been  established  at  272,  000,  000  characters  per  month.  This 
storage  requirement  includes  the  accommodation  of  peak  traffic 
for  quarterly,  semi-annual  and  annual  reports. 

2.  Message  Retention  Period:  The  length  of  time  that  a  reporting 

Command's  RCS  must  be  maintained  on  the  master  file  has  a  direct 
effect  on  the  total  storage  requirement.  The  period  of  retention  is, 
in  turn,  directly  affected  by  patterns  of  message  receipt  and 
efficient  extracting  of  messages  for  data  edits  on  the  7080. 

The  most  common  pattern  of  message  receipt  is  that  the  first  trans¬ 
missions  are  received  at  least  three  or  four  days  prior  to  the  due  date,  and 
the  final  transmissions  are  received  approximately  eight  to  ten  days  after 
the  due  date,  e.  g.  , 

1st  10th  (due  date)  30th 


6th  (first  message)  20th  (last  message) 

The  normal  pattern,  therefore,  accounts  for  at  least  50%  of  the  report¬ 
ing  period.  Any  substantial  deviation  toward  earlier  and/or  later  reporting 
during  a  peak  period  could  seriously  inflate  this  basic  retention  period. 
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Messages  are  now  extracted  for  data  editing  in  blocks  of  100,  000 
records.  It  is  desirable  to  maintain  this  size  in  order  to  keep  7080  set-up 
time  at  a  minimum.  However,  it  should  be  noted  that  the  longer  the  records 
must  be  maintained  in  the  master  file  until  the  block  is  complete,  the  more 
storage  capacity  is  needed. 

Alternatively,  if  we  were  to  assume  that  all  factors  tending  to  reduce 
the  storage  requirement  actually  decreased  it  by  20%,  i.  e.  ,  to  approxi¬ 
mately  218,  000,  000  characters,  it  would  be  possible  to  consider  the  group 
of  random  access  devices  that  provide  approximately  half  the  storage  of  the 
mass  random  (magnetic  card  or  strip)  devices.  However,  the  cost  of  these 
devices  is  approximately  double  the  cost  of  the  mass  random  devices. 

Inasmuch  as  the  mass  random  devices  meet  the  capacity  and  cost  tests, 
the  only  remaining  considerations  are  the  adequacy  of  seek  time  and  read/ 
write  time. 

The  limiting  time  factor  in  the  receipt  and  transmission  of  messages 
is  the  2400  baud  line  (240  characte r /second).  Using  peak  transfer  time,  it 
will  take  2.  76  minutes  to  send  and  receive  a  message.  If  we  assume  that 
the  system  has  just  simultaneously  received  and  transmitted  two  40,  000 
character  messages  and  the  peak  demand  for  the  mass  random  device  has 
now  begun  - 


T  ransfer 

Max.  Seek 

1. 

Move  incoming  message 
to  mass  random 

from  disk  to 

800  ms. 

600  ms. 

2. 

Move  outgoing  message 
to  mass  random 

from  disk  to 

800  ms. 

600  ms. 

Total  mass  random  time  = 

2800  ms. 

1600  ms. 

1200  ms. 

It  is  evident  that  the  mass  random  device  seek  and  read/write  times 
are  adequate  to  permit  real-time  operations.  That  is,  the  mass  random 
time  requirement  is  less  than  2%  of  the  time  it  takes  to  receive  or  transmit 
a  message.  The  remaining  time  available  on  the  mass  random  device 
could  be  used  to  dump  messages  to  tape  for  external  processing.  The 
cost /performance  characteristics  of  several  typical  equipments  are  shown 
in  Figure  6. 
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TRANSFER  RATE  STORAGE  CAPACITY  AVERAGE  ACCESS  TIME 

(Thousands  of  characters  per  second)  (Millions  of  characters)  (Milliseconds) 


AVERAGE  ACCESS  TIME  VS,  COST 


Dollars  Rental/Month 
STORAGE  CAPACITY  VS.  COST 


Dollars  Rental/Month 
TRANSFER  RATE  VS.  COST 


Dollar®  Renta l /Month 

Figure  9:  COST  PERFORMANCE  CHARACTERISTICS 


APPENDIX  I 


INTERNAL  SYSTEM  MESSAGE  HEADERS 


Each  message  that  is  stored  on  the  mass  random  device  will  include 
an  internal  system  message  header.  The  header  length  is  400  characters 
long,  containing  an  80- character  summary  and  a  copy  of  each  of  the 
AUTODIN  and  text  headers  and  trailers.  The  internal  message  header  will 
be  used  by  the  log  and  store  module  to  correctly  catalog  each  message. 
Further,  it  will  be  used  to  aid  in  reconstruction  of  the  system  tables  in 
case  of  Disk  destruction. 


Position 

Char 

Meaning 

1 

R 

Store  RCS  File 

K 

Store  Reject 

T 

Store  Teletype  File 

Z  -  5 

Binary 

Message  Length  Logical  Records 

Including  Header 

6 

T 

Classification 

S 

C 

u 

7 

c 

LMF-CC 

s 

LMF-SC 

D 

LMF-DD 

B 

LMF-BB 

I 

LMF-II 

8  -  14 

Call  Sign  of  Originator 

15  -  18 

Station  Serial  Number 

19  -  21 

Julian  Date 

22  -  25 

Time  Filed 

26  -  29 

Binary 

Text  Message  Record  Count 

30 

Blank 

No  Text  Header 

"X" 

Text  Header  Present 

31  -  44 

RCS  Number 

45  -  48 

Record  Length 

49  -  50 

Blocking  Factor  of  Original  Message 

51 

R 

Resubmission 

s 

SUS/DUP 

B 

Both 

52  -  55 

Binary 

Received  MSG  Number  This  Station 

(Cross  from  Log) 

56  -  58 

Message  Number 

59  -  64 

As  of  Date  YYMMDD 

65 

Command  Code 

66  -  67 

Error  Message  Codes 

Figure  10  (a):  INTERNAL  SYSTEM  MESSAGE  HEADERS 
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Figure  10  (b):  INTERNAL,  SYSTEM  MESSAGE  HEADERS  (C 
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APPENDIX  I  (Continued) 


APPENDIX  II 


TABLES 


Mass  Random  and  Disk  Storage  Formats 

In  order  to  design  the  portions  of  the  system  which  require  random 
access  ability  in  such  a  way  as  to  provide  hardware  independence,  a  logical 
Storage  System  was  developed.  Files,  such  as  logs,  which  require 
sequential  processing  will  not  be  allocated  within  the  logical  Storage  System, 
This  logical  storage  scheme  will  be  used  on  both  the  mass  random  and  the 
disk  devices. 

The  file  space  made  available  for  message  storage  on  the  mass  random 
device,  and  for  tables  and  buffers  on  the  disks,  will  be  organized  into  fixed- 
length  blocks.  Each  block  will  have  a  logical  record  number,  starting  from 
1.  The  equipment  manufacturer  will  provide  an  algorithm  by  which  the 
logical  record  number  can  be  converted  to  a  physical  device  address.  The 
data  portion  of  each  logical  record  will  be  1200  characters;  additional 
characters  can  be  added  to  provide  error  (i.  e.  ,  bad  track)  sentinels. 

Table  Organization 


Access  to  a  message  stored  on  the  mass  random  device  is  provided 
through  a  hierarchy  of  tables.  These  tables  are  in  core  and  on  the  disks. 
By  having  the  tables  reside  on  disk,  the  status  information  is  available 
without  access  to  the  slower  mass  random  device. 

A.  RCS  Core  Table 


The  RCS  Core  Table  is  the  first  table  used  in  the  storage  and 
retrieval  of  any  system  information.  It  is  a  list  of  all  the  current 
RCS's  recognized  by  the  system,  with  the  "as  of  date".  Associated 
with  each  RCS  "as  of  date"  entry  is  a  logical  record  number  pointing 
to  the  RCS  Command  Table  location  on  the  disk.  There  is  a  counter 
for  this  table  indicating  the  number  of  current  active  RCS’s  in  the  table. 

Al.  Command  Validation  Table 

B.  RCS  Command  Table 


For  each  active  RCS,  there  is  a  Command  Table.  This  is  a  list 
of  all  the  reporting  Commands  for  that  RCS.  Each  Command  has  a 
pointer  which  identifies  the  RCS  Command  Message  Table  for  that 
Command. 
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APPENDIX  II  (Continued) 


C.  RCS  Command  Message  Table  (Disk) 

For  each  reporting  Command  of  each  RCS,  there  is  an  RCS 
Command  Message  Table.  This  table  is  the  equivalent  to  the  RCS 
index  cards  in  the  Manual  System.  It  is  in  this  table  that  a  pointer 
exists  to  the  location  of  a  message  on  mass  random.  There  is  a  space 
for  each  message  number  expected  from  that  Command.  (Provision 
exists  for  overflow  conditions.  )  The  message  number  entry  is  located 
by  displacement  in  the  table. 

Example:  Figure  14  illustrates  the  method  used  in  retrieving  AFOlO's 

fifth  message  from  SAC. 


Counter  1 

A 

RCS 

Pointer 

As  of  Date 

_ -'-v _ 

Counter: 


RCS: 

Pointer: 


As  of  Date: 


4  Characters  (32  Binary  Bits)  -  Binary 

A  binary  number  representing  the  number  of  active  entries 
in  the  table. 

14  Characters  -  BCD 

The  RCS  symbol  left  justified. 

4  Characters  -  Binary 

A  binary  number  indicating  the  logical  record  number  of 
the  RCS  Command  Table. 

6  Characters  -  BCD 
YYMMDD 
YY  =  Year 

MM  =  Month 
DD  =  Day 


Figure  11:  RCS  CORE  TABLE 
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APPENDIX  II  (Continued) 


ISYSTEM  PARAMETER 


ACTIVE 

ENTRIES 

ALERT 

OUTPUT 

BLOCKING 

Command 

Code  Status 


i 


9  Characters 

Software  parameters  to  be  used  for  dynamic 
table  allocation,  and  multiple-logical  record 
tables. 

4  Characters  -  Binary 

A  binary  number  indicating  the  number  of 
entries  in  this  table. 

1  Character  -  BCD 

A  flag  used  to  indicate  issue  of  alert  reports 
upon  changes  to  any  status  entry. 

2  Characters  -  Binary 

The  standard  output  factor  to  be  used  in  tape 
dump. 

1  Character  -  BCD 

The  1- character  Command  Code  of  each 
reporting  Command. 

4  Characters  -  Binary 

A  binary  pointer  to  the  logical  record  con¬ 
taining  the  RCS  Command  Message  Table. 

1  Character  -  BCD 

An  indicator  as  to  the  status  of  each  reporting 
Command. 

Figure  12:  RCS  COMMAND  TABLE  (DISK) 


System  Parameters: 


Active  Entries: 


Alert: 


Output  Blocking  Factor: 


Command  Code: 


Pointer: 


Status : 
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APPENDIX  II  (Continued) 


k 


SYSTEM  PARAMETERS 


Istorage] 

|  ~~1  High  Message  Number 

|  [  Total  Messages  Received 

I  Number  Messages  in  Complete  Report 


]  RCS  -  Command  Alert  Flag 
"I  Status 


Mode 


System  Parameters:  9  Characters 

Storage:  4  Characters 

A  pointer  to  a  table  used  by  the  system  to 
allocate  mass  random  storage  for  a  message. 

High  Message  Number:  3  Characters  -  BCD 

The  highest  message  number  received  at  this 
time. 

Number  Messages  in  Complete  Report: 

3  Characters  -  BCD 

Message  number  of  text  trailer  received. 

1  Character  -  BCD 

Signal  to  issue  alert  report  upon  change  of  status 
or  reception  of  any  message  for  this  RCS 
Command. 

1  Character  -  BCD 
Status  of  Reporting  Command 

RCS  COMMAND  MESSAGE  TABLE 


RCS  -  Command  Alert: 


Status : 


Figure  13: 
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APPENDIX  II  (Continued) 


Start: 

Number: 

Mode: 

Message  Status: 

Message  Alert: 


4  Characters  -  Binary 

Logical  record. number  of  first  record  of 
message  on  mass  random. 

4  Characters  -  Binary 

Number  of  logical  records  used  to  store 
message. 

1  Character  -  BCD 

The  LMF  mode  of  message. 

1  Character  -  BCD 

Status  of  message  (not  received,  received, 
dumped,  etc.  ) 

1  Character  -  BCD 

Request  to  issue  alert  report  upon  receipt  of 
message. 


Figure  13:  RCS  COMMAND  MESSAGE  TABLE  (Concluded) 


Figure  14:  TABLE  FLOW 
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APPENDIX  III 


FORMAT  EDITS 


Card  Columns  Field  Description 

Edit  Procedure 

AUTODIN  Header 


39  -  40  Start  of  Routing  Signal 

--identifies  the  AUTODIN 
header. 

1  Precedence 

MXn  or  ffYn  entries  will 
cause  this  message  to  be 
printed  on  the  line  printer. 

2  -  3  Language  Media  Format 

If  CC3  is  ,rTn,  print  the 
message  and  abort  text  edit 
routines.  If  entry  is  tfSCH, 
branch  to  Single  Card  edit 
routine. 

30  -  33  Record  Count 

Store  for  later  validation. 

Text  Header 


1  -  6  Text  Header  Identification 

Must  contain  "TEXHDR" 

8-21  RCS  Number 

If  there  is  an  entry,  it  must 
pass  TLU. 

24  -  29  As  of  Date 

Must  pass  the  TLU  edit  with 
the  RCS  Number. 

32  Resubmissions 

If  entry  is  MRM,  bypass 
duplicate  test.  If  original 
message  has  been  extracted 
for  report  processing, 
flash  an  alert  to  ACQT. 

42  -  44  Message  Number 

Test  for  numerics.  Test 
for  equal  or  less  than  final 
message  number. 
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APPENDIX  IH  (Continued) 


FORMAT  EDITS 


Card  Columns  Field  Description_ Edit  Procedure 


Text  Header 

(Continued) 

46  -  49 

Record  Length 

Store  and  compare  against 
data  records. 

71  -  77 

TO/FROM 

From  field  must  equal  data 
record  Command  Code  if 

CC  78-80  are  blank. 

78  -  80 

Command  Being  Serviced 

If  there  is  an  entry,  it  must 
equal  the  Command  Code  in 
data  records  and  pass  the 
RCS-Command  TLU. 

Text  Trailer 

1  -  6 

Text  Trailer  Identification 

Must  contain  MTEXTLRn. 

7  -  45 

Duplicate  of  header  fields 

Must  compare. 

49-51 

Total  Number  of  Messages 

Used  by  query  program  to 
identify  missing  message 
number. 

AUTODIN  Trailer 

1  -  38 

Duplicate  of  Header 

All  fields  except  record 
count  must  be  equal. 

Record  Count  (CC  30-33) 
may  be  "MTMS11  in  header 
and  have  a  valid  entry  in 
the  trailer. 
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APPENDIX  IV 


RCS  DATA 


Monthly  RCS's 


RCS  Number  No.  of  Location  of  Total  Record  Count 

Commands  CMP.  Code (All  Commands) 


1  HAFA1 

1 

2-4 

6,  000 

HAFXDDC39 

8 

70 

1,  559 

HAFC42 

13 

4 

2,  535 

6  HAFE6 

22 

3-4 

12, 027 

8  HAFE6 

22 

3-4 

12, 356 

2  HAFM18 

17 

4 

7,966 

HAFM22 

16 

77 

68, 357 

HAFM2  6 

17 

4 

16,  657 

HAFOIOA 

23 

2 

530, 316 

HAFOIOD 

19 

2 

3,  347 

HAF018 

1 

1 

2,  500 

3  HAFP2 

20 

1-3 

10, 867 

HAFP212 

17 

1 

? 

1  HAFQ2 

22 

2-4 

24, 972 

4  HAFQ2 

22 

2-4 

3,  126 

HAFXCSQ1 6 

16 

2-4 

417 

1  HAFS11 

14 

29 

6,  314 

5  HAFS11 

13 

7 

8,  627 

HAFY20 

2 

20-22 

11, 000 

1  HAFZ28 

15 

11 

1,  391 

2  HAFZ28 

18 

11 

2,481 

Monthly  Totals 

318 

732, 815 
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APPENDIX  IV  (Continued) 


RCS  DATA 


Quarterly  RCS's 

RCS  Number  No.  of  Location  of  Total  Record  Count 

Commands  CMP.  Code  (All  Commands) 


HAFC28 

22 

7-8 

17, 055 

HAFC169 

16 

4 

5,  231 

4  HAFE6 

22 

2-3 

17, 713 

JCS1026 

17 

80 

6,  842 

HAFK14 

17 

9 

79,870 

3  HAFM18 

16 

4 

5,  030 

HAFOIOB 

8 

2 

109, 511 

HAFOIOC 

22 

2 

18, 804 

HAFP32 

16 

1-3 

2,  319 

HAFP194 

17 

1 

? 

2  HAFQ2 

21 

1  -3 

6,  007 

DDI  &  LQ612 

1 

2-4 

17, 600 

Quarterly  Totals 

195 

285,  982 

Semi-Annual  RCS's 

RCS  Number 

No.  of 

Location  of 

Total  Record  Count 

Commands 

CMD.  Code 

(All  Commands) 

Wartime  Req. 


Rept. 

23 

2 

? 

11  HAFE6 

22 

4-5 

1,030 

HAF013 

23 

1 

183, 449 

HAFP3 

20 

? 

61, 900 

HAFP124 

23 

2-4 

? 

HAFQ21 

21 

1  -3 

61, 703 

HAFS105 

16 

1  5 

3,  181 

1  HAFZ17 

19 

1 

459, 780 

4  HAFZ17 

18 

1 

174, 230 

Semi-Annual  Totals 

185 

945,  273 
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APPENDIX  IV  (Continued) 


RCS  DATA 


Annual  RCS's 


HAFXDDJ9 

21 

4-6 

HAFC28 

22 

7-8 

HAFC128172 

18 

'  76-77 

HAFC39D 

23 

1  -3 

HAFXCSQ17 

21 

3-4 

1  DDCOMPA594 

21 

1-3 

Annual  Totals 

126 

GRAND  TOTALS  824 


16, 544 
15,  218 
21,097 
7,  200 
14, 952 
17, 441 


92, 452 


2,  056,  522 
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